Background

This pull request is part of a series of pull requests to add a full IndexedDB implementation of the EventCacheStore (see #4617, #4996, #5090, #5138, #5226, #5274, #5343, #5384, #5406, #5414, #5497, #5506, #5540). This particular pull request adds a MemoryStore-backed implementation of EventCacheStoreMedia, as well as, IndexedDB-backed implementations for MediaRetentionPolicy-related functions.

Changes

The overarching change adds a MemoryStore-backed implementation of EventCacheStoreMedia for IndexeddbEventCacheStore. Furthermore, the implementation of EventCacheStore now delegates to the implementation of EventCacheStoreMedia via a MediaService nested in IndexeddbEventCacheStore.

Additionally, there are now implementations and tests for the following EventCacheStoreMedia functions.

• EventCacheStoreMedia::media_retention_policy_inner
  • Supported by IndexeddbEventCacheStoreTransaction::get_media_retention_policy
• EventCacheStoreMedia::set_media_retention_policy_inner

And finally, to support these queries, the CORE object store now has a primary key with key path id.

Caveats

EventCacheStoreMedia requires that the implementing type be Cloneable. Consequently, some rather minimal changes were required in order to support Clone.

There is, however, one notable change for supporting Clone, which is that IndexeddbEventCacheStore.inner went from being an IdbDatabase to an Rc<IdbDatabase>.

While this may seem like a problem in a concurrent environment, it is ultimately not an issue, as IndexedDB ensures that only a single transaction is running at a time. Any interfering transaction will be canceled by IndexedDB and return an error.

The downside of this architecture, however, is that it would require re-trying in a loop if multiple instances of IndexeddbEventCacheStore were contending for access.

An alternative would be to use a tokio::sync::Mutex in conjunction with an Arc, which would replace the loop with an await. The consequences of this are that the implementation of IndexeddbEventCacheStoreTransaction becomes rather tricky, as it seems to require a self-referential struct.

I'm not entirely sure why the EventCacheStoreMedia requires Clone and how it will be used, so I opted for using an Rc as it was far more straightforward and still a sound approach.

Future Work

• Add implementation of remaining EventCacheStoreMedia functions

• Public API changes documented in changelogs (optional)

Signed-off-by: Michael Goldenberg m@mgoldenberg.net